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REMARKS 

This amendment is submitted in response to the official action mailed November 
15, 2007, to more particularly define the invention and to patentably distinguish over the 
prior art of record. No new matter is presented. 

The specification is amended to insert a cross reference to related application, 
namely US Provisional Patent Application SN 60/399,834, filed July 31, 2002. 

Applicant submits a full set of replacement drawing sheets. Please cancel all the 
sheets of the original drawings and replace them with the concurrently submitted 
drawings, each of which is labeled "replacement sheet" in the upper margin. The 
replacement drawings are copies of the drawings of record but are pdf printings that are 
more legible than the scanned drawings of record. In addition, a number of the boxes 
and similar figures that contained gray shading as filed have been replaced with boxes 
having no shading or white backgrounds in a lined box as opposed to a gray shaded 
box. No new matter is presented. 

Claims 42-47, 49 and 52-59 were rejected as anticipated by US 4,785,408 - 
Britton under 35 U.S.C. §1 02(b). Claims 48 and 60 were rejected under 35 U.S.C. §103 
over Britton in combination with US 7,003,079 - McCarthy, cited for generating and 
storing a dialog creation summary or a call report summary. Claims 50 and 51 were 
rejected under 35 U.S.C. §103 over Britton in combination with US 6,850,603 - Eberle, 
cited for providing a policy option respecting a schedule affecting the execution date for 
a behavior. Applicant is pleased to note that the previous rejections based on US 
7,034,691 - Rapaport have apparently been overcome. 

It is apparent that the rejections under 35 USC §§102 and 103 rely substantially 
on Britton. The claims have been amended to particularly and distinctly define the 
aspect of the invention concerning the application of wizards as disclosed in the 
application at paragraphs [0016], [0049], [0050] and [0057] of the application as 
published and as set forth in several of the original claims. There is no disclosure or 
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suggestion in Britton of the application of software wizards to the field of telephone 
dialog composition and execution. Britton teaches away from this subject matter, now 
distinctly claimed, and whether considered alone or in combination with the other prior 
art, does not disclose or render obvious the invention claimed as a whole. 

Composing a dialog for interaction with remote human subjects is a category of 
programming. There are certain components ("dialog components") that can be chosen 
by the configuror who sets up the dialog. The dialog components need to be connected 
to one another as a sequence of operations. Where input and output are required, the 
dialog components need to be connected to data storage sources containing relevant 
information to be used as variable values (e.g., phone numbers, personal identifications 
such as account numbers, etc.) and to input/output devices where dialing signals and 
audio clips can be encoded and decoded (composed and read-out, or read-in and 
interpreted). For input, voice recognition or keypad tone signaling recognition routines 
may be needed to decode and make sense of responsive input data leading to variable 
values that can be stored in associated database fields. The various alternatives and 
options need to be defined into a coherent program by selecting the dialog components, 
coupling the data flow sources and destinations to data elements that are variables or 
constant values, or perhaps to other dialog components that will derive values that are 
passed among the dialog components. In short, there are many details to be 
determined and set down into the configured dialog in order for the dialog to carry out its 
functions. 

In composing programs, there is a concept of program modules, in some 
instances known as subroutines. This concept is found in applicant's invention and also 
in Britton and other prior art. As described above, it is necessary to determine and set 
down in the configured dialog the details necessary for the dialog to carry out its 
functions, in particular to sequentially arrange program modules such as subroutines 
and to provide the arguments and exchanges of variable values that govern their 
operation. In Britton and other conventional prior art, the configuror is required to 
selectively couple the various modules, and the configuror is required to specify the 
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details of transaction handling. See Britton at col. 4, lines 64-68, which state that the 
producer parameterizes each interaction module by specifying the details of transaction 
handling. The producer interface (namely the program that assists with composition) 
suggests default parameters where appropriate. The producer interface (program) does 
not require or constrain or limit what the configuror can do. Therefore, the configuror 
must understand how the modules work in order to parameterize the interaction 
modules and thereby specify the details of transaction handling. 

Applicant's claimed invention differs from Britton by the application of software 
wizards. A software wizard is a process that determines what options shall be offered 
to the configuror. The options offered are limited to sequences and parameters that are 
predetermined to be operational. A software wizard embodies a procedure wherein 
initial options that are chosen by the configuror, cause constraints to arise with respect 
to subsequent options that are offered as alternatives to the configuror. The wizard 
process leads the configuror along a sequence of selections that force the configuror to 
choose among options that will result in an operational dialog. 

Applicant's use of software wizards has beneficial aspects. The configuror need 
not understand the minimum requirements of the dialog modules and how the modules 
work or fit together. The wizard will not present options to the configuror that are 
inoperative. Software wizards have an adverse quality as well, because by limiting the 
available choices to tried and true alternatives and sequences only, the wizard prevents 
a configuror from departing from the tried and true, even if the configuror might be an 
expert with the knowledge of how to produce an improved level of performance or 
function by departing from the predetermined safe path. 

Britton requires the configuror (termed the "producer" by Britton) to make the 
decisions. Britton therefore requires a level of understanding and skill on the part of the 
configuror. Applicant's claimed invention differs from Britton by comprising wizards that 
make it impossible for the configuror to err in any way other than to choose an 
unintended alternative among plural alternatives wherein both such alternatives 
successfully achieve their respective functions. 
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The claims as amended are limited to dialog configuration using one or more 
wizards. This subject matter is supported in the application as filed and is not met by 
Britton and would not result from any routine combination of aspects from Britton and 
the other prior art. 

A software "wizard," in context, denotes a process that defines a constrained set 
of possible selections in defining parameters, wherein the constrained set is limited by 
sequential presentation of options and by the particular options presented, to lead 
unerringly to an operational set up. As defined in Wikipedia: 
Wizard (software) 

A wizard is a user interface element where the user is presented with a sequence of 
dialog boxes. Through these dialog boxes, the user is led through a series of steps, 
performing tasks in a specific sequence. Sometimes it may otherwise be possible to 
reach the same result without using the wizard. However, it may be easier to perform 
this task using the wizard, especially for complex or infrequently performed tasks 
where the user is unfamiliar with the steps involved. 

The concept, first introduced in Microsoft Publisher in 1991 , was first used in an 
operating system in Microsoft's Windows 95. The most commonly-used wizard at the 
time was the Internet Connection Wizard, which was renamed to the "New Connection 
Wizard" in later versions of Microsoft Windows. This wizard guides the user through the 
process of creating a connection to the Internet, or to a Virtual Private Network. 

By 2001, wizards had become commonplace in most consumer-oriented operating 
systems, though not necessarily by the same name. In Mac OS X, for example, they 
are called "Assistants"; some examples include the "Setup Assistant", which is run 
when one boots the Macintosh for the first time, and the "Network Setup Assistant", 
which has similar function to the aforementioned "New Connection Wizard". GNOME 
also has a similar construct which they call a "Druid". 

Web applications, such as an airline booking site, also make use of the wizard 
paradigm to complete lengthy interactive processes. Oracle Designer also uses 
wizards extensively. 

By contrast, expert systems guide the user through a series of (usually yes/no) 
questions to solve a problem, and tend to make use of artificial intelligence or other 
complex algorithms. Some consider expert systems as a general category that 
includes all problem-solving programs including wizards. 

Wizards were controversial among user interface designers when they first gained 
widespread use. This controversy centered around the fact that wizards encourage 
modal windows, which its opponents consider antithetical to proper human interface 
design. 
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Further support is found in Microsoft's guide for programming. The Microsoft 
Network Library (see http://msdn2.microsoft.com/en-us/library/ms737820(VS.85).aspx) 
states regarding Wizards: 

Scope and Audience for a Wizard 

Follow the published guidelines for creating a wizard. Users are better served by a 
common look and feel. Also, the standard elements have usability tested well and are 
there for a reason. Microsoft Internet Explorer 5.0 is shipping with a wizard common 
control, which should encourage future applications to settle on a common look and 
feel. 

Avoid a wizard design that requires the user to leave the wizard to complete a task. 
Less-experienced users are often the primary users of a wizard. They need a lot of 
handholding and easily get lost. Asking them to leave the wizard temporarily or to keep 
it onscreen while doing something else (e.g., working with the content of a document) 
is usually too much to ask. Make sure that users can do everything from within the 
wizard. 

Always provide step-by-step instructions. Wizards that don't provide step-by-step 
instructions aren't wizards. A major goal for a wizard is to shield users from a more- 
complicated Ul. Adding Back and Next buttons to a full-scale Ul does not constitute a 
wizard. 

For complex tasks, focus on the most common scenarios, provide multiple paths, or 
create multiple wizards. Don't try to cram all the functionality into one wizard or path 
through the wizard. Carefully examine users' tasks to understand what things the 
wizard must support well. Consider implementing different paths through the wizard for 
different user experience levels. Also consider breaking a big wizard up into smaller, 
more focused wizards. 

Consider advanced user needs when contemplating having a wizard as the only Ul. 
Users with extensive domain knowledge and/or extensive GUI experience want their 
work to be efficient and they want access to all of the functionality. These goals can be 
at cross-purposes with a wizard. Having a wizard as the only Ul for a feature works 
when the task itself is fairly simple or multiple paths are provided through the wizard. 

Be careful to not automate too much of the process. Carefully study users' tasks when 
creating a wizard. Be sure that users will be comfortable with the amount of control 
they have over the process.. 



Britton discloses suggestion of default values by the producer interface (which is 
Britton's name for the programmed processor assisting the human producer). See col. 
4, lines 66-68. However it is the producer who explicitly sets the values of several 
parameters. That is, the human sets the parameters in Britton and they might or might 
not be default values suggested by the producer interface. See col. 5, lines 1-3. As 
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such, Britton lacks the concept of a wizard, wherein the producer (the configuror in 
applicant's terms) is guided by the interface through a series of selections wherein 
predetermined alternatives offered and choices made in the earlier selections, 
determine what alternatives are made available in subsequent selections, forcing the 
producer to arrive in the end at one of a finite set of operational states that are known to 
work. 

Applicant has now amended the claims to particularly and distinctly define the 
invention over Britton, alone and in combination with McCarthy and/or Eberle. No new 
matter is presented. The differences between the invention and the prior art are such 
that the subject matter claimed as a whole is not shown to have been known or obvious. 

When operating a programmable dialog composing system as in Britton, the 
unconstrained availability of parameter options that the configuror/producer might 
accept, means that the configuror/producer must have a comparable level of 
understanding as to how the dialog components are structured and how they function. 
It is only with this knowledge that the configuror in Britton can be expected to 
successfully compose an operational dialog. The configuror in Britton must understand 
the order in which the dialog modules might be sequenced, so that conditions 
necessary to operation of a later module in a sequence have been established by 
operation of earlier modules when necessary. The configuror in Britton must 
understand how the outputs of any given module couple to inputs of other modules. 
The versatility that the unconstrained selection of parameters provides in Britton comes 
with a cost: The configuror must understand how the modules work in order to make 
unconstrained selections. 

Applicant's invention relies on one or more wizards. The wizards are particularly 
and distinctly claimed. According to applicant, alternative routes that may be taken by 
the configuror effectively are pre-mapped by the wizard. The configuror can proceed 
successfully through the maze of potential choices of modules, sequences, conditions, 
parameters, etc., because the wizard will only permit the configuror to stay on the 
straight and narrow path to a successful conclusion, namely to set up one of a limited 
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number of operational configurations that are offered by the wizard. The configuror 
need not understand how the modules operate or interact, or expectations or limitations 
on which the modules rely. These details are obviated by the wizard. 

There is no such wizard disclosed in Britton or the other prior art. Applicant's 
invention claimed as a whole is novel. There is no basis for one to expect that the 
person of ordinary skill who sought to improve programmed assistants for dialog 
composition would perceive predictable success by taking away the options available to 
a configuror in Britton. One would routinely expect that removing options would prevent 
or retard the configuror from setting up a dialog according to the configuror's choice. 
Only applicant discloses or suggests applying a wizard, thus restricting the availability 
and sequenced offering of options, with the resulting improvement that unsophisticated 
users with virtually no knowledge or understanding of the specifications and manner of 
operation of dialog modules, can efficiently produce dialogs that are assured to work for 
their intended purposes. 

The claims now presented are definite and find enabling support in the original 
disclosure. The invention claimed as a whole is not disclosed in the prior art now of 
record. The differences between the invention and the prior art are such that the 
subject matter claimed as a whole is not shown to have been obvious. The claims as 
amended now include system claims 42-66 and method claims 67-70. 

Reconsideration and allowance of claims 42-70 are requested. 

Respectfully submitted, 

Date: April 14, 2008 /Stephan Gribok/ 
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